Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@registration/registration-services/src/main/java/io/mosip/registration/update/ClientIntegrityValidator.java`:
- Around line 57-64: The fallback branch in ClientIntegrityValidator should not
treat opening a JarFile with verification enabled as sufficient when
trustedCertificate is missing. Update the logic around verifyIntegrity and the
else path so the client integrity check explicitly reads/verifies signed JarFile
entries (or otherwise fails fast) instead of logging success after constructing
JarFile only. Make sure the missing provider.pem/provider.cer case fails closed
and does not bypass integrity enforcement.

In
`@registration/registration-services/src/main/java/io/mosip/registration/update/ClientSetupValidator.java`:
- Around line 102-109: The same-version validation path is using a stale
constructor-loaded libManifest, so jar checksum checks can miss updates after
the manifest rewrite. Refresh or reload libManifest from the updated jar state
before iterating its entries in ClientSetupValidator, and make sure the checksum
validation logic uses the current per-jar manifest data rather than the original
local copy.
- Around line 160-162: The IOException catch in ClientSetupValidator currently
hides the underlying manifest load failure by throwing a RegBaseCheckedException
without the cause. Update the exception handling in the manifest-loading path to
use the RegBaseCheckedException constructor that accepts the caught IOException,
so the failure reason is preserved for cases like permission or corruption
issues; keep the existing errorCode and label message, but pass e through when
rethrowing.

In
`@registration/registration-services/src/test/java/io/mosip/registration/test/update/ClientIntegrityValidatorTest.java`:
- Around line 55-80: The `ClientIntegrityValidatorTest` methods are sharing the
fixed working-directory `lib/MANIFEST.MF` path, which makes them flaky when test
order changes or when another test like `ManifestCreatorTest` also touches the
same file. Update `verifyClientIntegrityTest` and
`verifyClientIntegrityManifestPresentTest` to save the pre-existing
`lib/MANIFEST.MF` and `lib/` state before modifying them, then restore or clean
up that state in teardown/finally so the tests remain isolated and do not depend
on external filesystem state.

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@registration/registration-services/src/test/java/io/mosip/registration/test/update/ClientIntegrityValidatorTest.java`:
- Around line 60-75: In ClientIntegrityValidatorTest, the setup and teardown
logic around lib/MANIFEST.MF ignores failures from delete() and renameTo(),
which can leave the manifest in an unexpected state. Update the backup/restore
flow in the init/restore methods to fail fast by checking each file operation
result or using checked file move/delete APIs, so test state is reliably
restored via libManifest, libManifestBackup, and restoreLibManifest.

---

Outside diff comments:
In
`@registration/registration-services/src/test/java/io/mosip/registration/test/update/ClientIntegrityValidatorTest.java`:
- Around line 81-84: The verifyClientIntegrityTest currently only asserts
SecurityException, which can pass for unrelated failures; update the test around
ClientIntegrityValidator.verifyClientIntegrity() to verify the missing-manifest
path specifically by asserting the nested cause or message mentions
lib/MANIFEST.MF, so the test exercises the intended failure instead of any
generic security error.